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REMARKS 

This communication responds to the Office Action dated September 13, 2004. In that 
Office Action, the Examiner rejected claim 38 under 35 U.S.C. 1 12, first paragraph as failing to 
comply with the written description requirement. The Examiner further rejected claim 38 under 
35 U.S.C. 102(b) as being unpatentable over U.S. Patent No. 4,491,725 to Pritchard. These 
rejections are respectfully traversed for the reasons set forth below. 

Rejection under 35 U.S.C. $ 1 12 

Claim 38 was rejected under 35 U.S.C. § 1 12, first paragraph, as failing to comply with 
the written description requirement. Specifically, the Examiner asserted that the specification 
lacks written description in the description on the validating step. The Examiner argued that it is 
unclear how data records are being validated using a diagnostic code and/or a treatment code in 
order to process the medical claims. The Examiner further argued that it is unclear and lacks 
description on how a predefined relationship between a diagnosis code and a treatment code in 
the validated data records and a predefined episode treatment categories are being read. This 
rejection is traversed for at least the following reasons. 

The Examiner may be confused as to the actual language of the claim. The Examiner 
asserted that it is unclear "how data records are being validated using a diagnostic code and/or a 
treatment code in order to process the medical claims." Claim 38 recites "validating each of the 
at least one of a plurality of records for at least one of a diagnosis code and a treatment code." 
Thus, claim 38 merely requires validating that at least one of a diagnosis code and a treatment 
code are present in each of the at least one of a plurality of records. 

Regardless of the Examiner's interpretation of the claim language, the applicants 
respectfully submit that "validating each of the at least one of a plurality of data records for at 
least one of a diagnosis code and a treatment code" and "reading at least one pre-defined 
relationship between the at least one of a diagnosis code and a treatment code in the validated at 
least one of a plurality of data records and pre-defined episode treatment categories" are fully 
supported by the present Application. 
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As stated in the Response filed January 24, 2002, a validation step is performed in the 
present application during the RAM process that precedes the grouping of the validated at least 
one of a plurality of data records to an episode treatment category based upon the pre-defined 
relationship. The validation step is described at pages 25-29 of the first substitute specification 
and, particularly, at page 26, lines 20-28: 

FIG. 7 depicts an analytical process of the preferred embodiment that includes initializing 
701 RVU and line number for each line of the claim and sorting 702 by RVU 
(descending) and CPT and charge in order to prepare for proper analysis by Medicode's 
Claims Edit System (CES). Then 703 line items are split into two groupings of surgical 
assistant modifiers and all other modifiers in separate groups. Each of the two groups is 
then validated 704 against disease classification codes (ICD 9); procedure edits rules 705 
(CES tables) and unbundled/rebundle edits 706 are performed. Present application, first 
substitute specification, page 26, lines 20-27, 

Again, as stated in the Response filed January 24, 2002, the translation of the source code from 
the Microfiche Appendix explains that, in order for an episode of care to be generated for a 
medical condition corresponding to a selected Index Code, the patient's history must include 
records containing occurrences of one or more ICD-9 codes that fall in the range of ICD-9 codes 
specified in the Index Detail Table for such Index Code having an Indicator value of "I" or "ML" 
The ICD-9 codes having an Indicator value of "I" or "MI" for a given Index Code are the ICD-9 
codes that identify a diagnosis that, in turn, identifies the particular medical condition specified 
by such Index Code. 

After RAM processing of the data, episodes of care are determined: 

The next step in transforming raw data into a useful database is to determine episodes of 
care for the data that has already undergone RAM processing. In the invention, a 
database is created which contains profiles for various diagnoses, chronic or otherwise, 
including complications indicators. Creation of the database depends on accurately 
defining an episode of care ("EOC") for each diagnosis. An episode of care is generally 
considered to be all healthcare services provided to a patient for the diagnosis treatment 
and aftercare of a specific medical condition. The episode of care for a single disease is 
depicted in FIG. 2. In the simplicity of the figure, it can be seen that for the diagnosis in 
question, all healthcare services provided between onset and resolution should be 
incorporated into the database. Present application, first substitute specification, page 
28, lines 18-27. 

In use, each potential episode of care is validated: 
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Each potential episode of care is then checked to determine if the index code in question 
appears on the required number of dates of service within the EOC 1208. If the index 
code does not appear the required number of times, the potential EOC is pended. Present 
application, first substitute specification, page 31, lines 14-17. 

The invention generates a database of EOCs against which claims may be checked: 

The method for defining an entire episode of care provided in the invention is used to 
construct a database of EOCs based on billing data that has been filtered to eliminate data 
irrelevant to the diagnosis which would lead to an erroneous profile. Essential to the 
determination of an EOC are certain qualifying circumstances. These circumstances are 
managed through the use of interrelational qualifying tables, to provide a mechanism for 
sorting patient history for the occurrence of specific procedures or ICD codes that are 
requisite for an EOC to be valid. Present application, first substitute specification, page 
29, line 31 -page 30, line 4. 

The Response filed January 24, 2002 explained the grouping of validated data records to an 
episode treatment category. The grouping necessarily flows from the reading of at least one pre- 
defined relationship between the at least one of a diagnosis code and a treatment code in the 
validated at least one of a plurality of data records and pre-defined episode treatment categories. 
Accordingly, some of that discussion will be repeated here. 

First, 1205, a temporary file is created based on combining the authorized and/or 
disallowed ICD codes that are associated with a given index code in the Index Global 
Table (listing preventative and aftercare codes) and the Index Detail tables. The 
temporary file is created using the Index Table, which determines whether or not the 
Index Table only should be accessed or whether the Index Global Table is also necessary 
for drafting the temporary file. Second, 1202, the raw data set which has undergone 
RAM processing is sorted by index code (i.e. principal diagnosis) to find all patient 
records within a patient history having an occurrence of a particular index code. It is 
contemplated that the number of occurrences of a particular index code can be defined by 
the user. In the present embodiment, it is recommended that the particular index code 
being sought occur on at least two different dates of service. Third, 1203, the valid 
components of these patient records are then checked against the interrelational 
qualifying tables to identify ICD codes associated with the chosen index code. In 
addition, the patient records are searched for any comorbidity ICD codes that would 
disqualify the patient record for including in the EOC (such as diabetes or renal failure). 
Present application, first substitute specification, page 30, lines 8-23. 

Thus, the specification sets forth each element of claim 38. More specifically, the specification 
sets forth: 
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(a) reading a medical claim data, input as at least one of a plurality of data records, into a 
computer memory; 

(b) validating each of the at least one of a plurality of data records for at least one of a 
diagnosis code and a treatment code; 

(c) reading at least one pre-defined relationship between the at least one of a diagnosis 
code and a treatment code in the validated at least one of a plurality of data records and 
pre-defined episode treatment categories; and 

(c) grouping the validated at least one of a plurality of data records to an episode 
treatment category based upon the pre-defined relationship, each episode treatment 
category having a dynamic time window defining a time period which validated at least 
one of plurality of data records may be grouped to an episode treatment category. 

Accordingly, reconsideration of the rejection under 35 U.S.C § 1 12, first paragraph is 
respectfully requested. 

Rejection under 35 U.S.C, § 102 

Claim 38 was rejected under 35 U.S.C. § 102(b) as being unpatentable over Pritchard 
(U.S. 4,491 ,725). This rejection is traversed at least for the following reasons. 

Pritchard discloses a medical insurance verification and processing system useful for 
patients and service providers to determine the amount that will be paid by an insurance carrier 
for a service: 

A selected embodiment of the present invention comprises a method for rapidly 
determining an insurance claim payment for a specified payment system. 

The information input into the system of Pritchard comprises patient information and service 
information. The system then determines what the insurance carrier will pay for that service. 

Pritchard does not disclose, teach or suggest anything relating to episode treatment 
categories. Accordingly, Pritchard does not disclose, teach or suggest "reading at least one pre- 
defined relationship between at least one of a diagnosis code and a treatment code in the 
validated at least one of a plurality of data records and pre-defined episode treatment categories" 
nor "grouping the validated at least one of a plurality of data records to an episode treatment 
category based upon the pre-defined relationship, each episode treatment category having a 
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dynamic time window defining a time period which validated at least one of plurality of data 
records may be grouped to an episode treatment category." 

The Examiner argued that "reading at least one pre-defined relationship between at least 
one of a diagnosis code and a treatment code in the validated at least one of a plurality of data 
records and pre-defined episode treatment categories" is taught by the abstract of Pritchard. The 
abstract, however, only teaches that the central brokerage computer converts the patient service 
code input by the service provider or MEDIC ARD into a particular service code for the patient's 
insurance carrier. This does not comprise reading a pre-defined relationship between at least one 
of a diagnosis code and a treatment code and pre-defined episode treatment categories. Again, 
Pritchard does not disclose, teach or suggest episode treatment categories. 

Similarly, the Examiner argued that Pritchard teaches "grouping the validated at least one 
of a plurality of data records to an episode treatment category based upon the pre-defined 
relationship, each episode treatment category having a dynamic time window defining a time 
period which validated at least one of plurality of data records may be grouped to an episode 
treatment category." Specifically, the Examiner argues that Column 5, lines 18 through Column 
9, line 49 teaches this. That portion of Pritchard teaches several components of the invention as 
well as use of the invention. The components include: a MEDICARD including information 
regarding the patient such as address, telephone number, and social security number (Pritchard, 
Column 5, lines 33-39), a local entry terminal and a magnetic strip reader (Pritchard, Column 6, 
lines 8-24), a patient file comprising a collection of information for a specific patient (Pritchard, 
Column 6, lines 25-46), and a code conversion table for a particular insurance carrier whereby 
the standardized AMA CPT-IV code can be converted by means of Table 72 into a specific 
service code for the given insurance carrier (Pritchard, Column 6, lines 47-56). Use of the 
invention comprises: a patient receiving a service from the provider or inquiring from a provider 
about the cost and insurance coverage for a service (Pritchard, Column 6, line 61 - Column 7, 
line 6), information from the MEDICARD is entered by the provider and a central brokerage 
computer determines if the MEDICARD is valid (Pritchard, Column 7, lines 7-36), the provider 
fills out a standardized insurance claim form and submits that form to the central brokerage 
computer (Pritchard, Column 7, lines 37-10), the central brokerage computer translates the CPT- 
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I code into a code for the selected insurance carrier, uses the service code to read the claim 
payment for that service code, and transmits the payment amount to the local service terminal of 
the provider (Pritchard, Column 8, lines 11-44), the patient and provider can then read the claim 
payment amount that the patient's insurance carrier will pay for the service (Pritchard, Column 
8, lines 44-64). Pritchard then discusses "assignment of claim payment provisions" of insurance 
carrier's and how claim payment may be done using the system. (Pritchard, Column 8, line 64 - 
Column 9, line 49), Again, Pritchard does not disclose, teach or suggest episode treatment 
categories nor grouping the validated at least one of a plurality of data records to an episode 
treatment category. 

Thus, it is respectfully submitted that Pritchard does not disclose, teach or suggest claim 
38 of the present application. Accordingly, reconsideration and allowance are respectfully 
requested. 

Conclusion 

This application now stands in allowable form and reconsideration and allowance are 
respectfully requested. 

Respectfully submitted, 

DORSEY & WHITNEY LLP 
Customer Number 25763 
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